Last-Mile TLS Interception: Analysis and Observation of the Non-Public HTTPS Ecosystem

Transport Layer Security (TLS) is one of the most widely deployed cryptographic protocols on the Internet that provides confidentiality, integrity, and a certain degree of authenticity of the communications between clients and servers. Following Snowden's revelations on US surveillance programs, the adoption of TLS has steadily increased. However, encrypted traffic prevents legitimate inspection. Therefore, security solutions such as personal antiviruses and enterprise firewalls may intercept encrypted connections in search for malicious or unauthorized content. Therefore, the end-to-end property of TLS is broken by these TLS proxies (a.k.a. middleboxes) for arguably laudable reasons; yet, may pose a security risk. While TLS clients and servers have been analyzed to some extent, such proxies have remained unexplored until recently. We propose a framework for analyzing client-end TLS proxies, and apply it to 14 consumer antivirus and parental control applications as they break end-to-end TLS connections. Overall, the security of TLS connections was systematically worsened compared to the guarantees provided by modern browsers. Next, we aim at exploring the non-public HTTPS ecosystem, composed of locally-trusted proxy-issued certificates, from the user's perspective and from several countries in residential and enterprise settings. We focus our analysis on the long tail of interception events. We characterize the customers of network appliances, ranging from small/medium businesses and institutes to hospitals, hotels, resorts, insurance companies, and government agencies. We also discover regional cases of traffic interception malware/adware that mostly rely on the same Software Development Kit (i.e., NetFilter). Our scanning and analysis techniques allow us to identify more middleboxes and intercepting apps than previously found from privileged server vantages looking at billions of connections. We further perform a longitudinal study over six years of the evolution of a prominent traffic-intercepting adware found in our dataset: Wajam. We expose the TLS interception techniques it has used and the weaknesses it has introduced on hundreds of millions of user devices. This study also (re)opens the neglected problem of privacy-invasive adware, by showing how adware evolves sometimes stronger than even advanced malware and poses significant detection and reverse-engineering challenges. Overall, whether beneficial or not, TLS interception often has detrimental impacts on security without the end-user being alerted

A Large-Scale Evaluation of High-Impact Password Strength Meters

Passwords are ubiquitous in our daily digital life. They protect various types of assets ranging from a simple account on an online newspaper website to our health information on government websites. However, due to the inherent value they protect, malicious people have developed insights into cracking them. Users are pushed to choose stronger passwords to comply with password policies, which they may not like much. Another solution is to put in place proactive password-strength meters/checkers to give feedbacks to users while they create new passwords. Millions of users are now exposed to these meters at highly popular web services that use user-chosen passwords for authentication, or more recently in password managers. Recent studies have found evidence that some meters actually guide users to choose better passwords -which is a rare bit of good news in password research. However, these meters are mostly based on ad-hoc design. At least, as we found, most vendors do not provide any explanation of their design choices, sometimes making them appear as a black-box. We analyze password meters deployed in selected popular websites and password managers. We document obfuscated open-source meters; infer the algorithm behind the closed-source ones; and measure the strength labels assigned to common passwords from several password dictionaries. From this empirical analysis with millions of passwords, we shed light on how the server-end of some web service meters functions, provide examples of highly inconsistent strength outcomes for the same password in different meters, along with examples of many weak passwords being labeled as strong or even excellent. These weaknesses and inconsistencies may confuse users in choosing a stronger password, and thus may weaken the purpose of these meters. On the other hand, we believe these findings may help improve existing meters, and possibly make them an effective tool in the long run

From Very Weak to Very Strong: Analyzing Password-Strength Meters

Millions of users are exposed to password-strength meters/checkers at highly popular web services that use user- chosen passwords for authentication. Recent studies have found evidence that some meters actually guide users to choose better passwords—which is a fairly rare-bit of good news in password research. However, these meters are mostly based on ad-hoc design. At least, as we found, most vendors do not provide any explanation of their design choices, sometimes making them appear to be a black box. We analyze password meters deployed in selected popular websites, by measuring the strength labels assigned to common passwords from several password dictionaries. From this empirical analysis with millions of passwords, we report prominent characteristics of meters as deployed at popular websites. We shed light on how the server-end of some meters functions, provide examples of highly inconsistent strength outcomes for the same password in different meters, along with examples of many weak passwords being labeled as strong or even very strong. These weaknesses and inconsistencies may confuse users in choosing a stronger password, and thus may weaken the purpose of these meters. On the other hand, we believe these findings may help improve existing meters, and possibly make them an effective tool in the long run

Challenges and Implications of Verifiable Builds for Security-Critical Open-Source Software

The majority of computer users download software from the Internet and run it directly on their machine. They expect applications to work as advertised, and implicitly trust them not to perform any malicious activities. For security-sensitive applications though, users need the assurance that what they downloaded is what has been officially released by the developers, and that it comes directly from audited sources to avoid surreptitious backdoors. However, the compilation process from source code to binary files, and more generally, the toolchain used in software packaging, has not been designed with verifiability in mind. Rather, the output of compilers is often dependent on parameters that can be strongly tied to the building environment, and may not be easily repeatable anywhere else. In this paper, we first manually replicate a close match to the official binaries of sixteen most recent versions of TrueCrypt for Windows up to v7.1a, a widely known open-source encryption tool, and explain the remaining differences that can solely be attributed to non-determinism in the build process. This experiment provides the missing guarantee on the official binaries, and makes audits on TrueCrypt's source code more meaningful. Also, it gives insights about what constitutes sources of non-determinism in a compilation process, which may help create future verifiable build processes. We also summarize challenges faced by Bitcoin, Tor, Debian and other Linux distributions in designing automated methods, such as deterministic and reproducible builds, for the verification of their official packages. Finally, we discuss a few suggestions for achieving deterministic builds

Challenges and Implications of Verifiable Builds for Security-Critical Open-Source Software

The majority of computer users download compiled software and run it directly on their machine. Apparently, this is also true for open-sourced software -- most users would not compile the available source, and implicitly trust that the available binaries have been compiled from the published source code (i.e., no backdoor has been inserted in the binary). To verify that the official binaries indeed correspond to the released source, one can compile the source of a given application, and then compare the locally generated binaries with the developer-provided official ones. However, such simple verification is non-trivial to achieve in practice, as modern compilers, and more generally, toolchains used in software packaging, have not been designed with verifiability in mind. Rather, the output of compilers is often dependent on parameters that can be strongly tied to the building environment. In this paper, we analyze a widely-used encryption tool, TrueCrypt, to verify its official binary with the corresponding source. We first manually replicate a close match to the official binaries of sixteen most recent versions of TrueCrypt for Windows up to v7.1a, and then explain the remaining differences that can solely be attributed to non-determinism in the build process. Our analysis provides the missing guarantee on official binaries that they are indeed backdoor-free, and makes audits on TrueCrypt's source code more meaningful. Also, we uncover several sources of non-determinism in TrueCrypt's compilation process; these findings may help create future verifiable build processes

From Very Weak to Very Strong: Analyzing Password-Strength Meters

Millions of users are exposed to password-strength meters/checkers at highly popular web services that use user- chosen passwords for authentication. Recent studies have found evidence that some meters actually guide users to choose better passwords—which is a fairly rare-bit of good news in password research. However, these meters are mostly based on ad-hoc design. At least, as we found, most vendors do not provide any explanation of their design choices, sometimes making them appear to be a black box. We analyze password meters deployed in selected popular websites, by measuring the strength labels assigned to common passwords from several password dictionaries. From this empirical analysis with millions of passwords, we report prominent characteristics of meters as deployed at popular websites. We shed light on how the server-end of some meters functions, provide examples of highly inconsistent strength outcomes for the same password in different meters, along with examples of many weak passwords being labeled as strong or even very strong. These weaknesses and inconsistencies may confuse users in choosing a stronger password, and thus may weaken the purpose of these meters. On the other hand, we believe these findings may help improve existing meters, and possibly make them an effective tool in the long run

A survey and analysis of TLS interception mechanisms and motivations

TLS is an end-to-end protocol designed to provide confidentiality and integrity guarantees that improve end-user security and privacy. While TLS helps defend against pervasive surveillance of intercepted unencrypted traffic, it also hinders several common beneficial operations typically performed by middleboxes on the network traffic. This issue has resulted in some parties proposing various methods that "bypass" the confidentiality goals of TLS by playing with keys and certificates essentially in a man-in-the-middle solution, and leads to new proposals that extend the protocol to accommodate third parties, delegation schemes to trusted middleboxes, and fine-grained control and verification mechanisms. To better understand the underlying motivation of such research proposals, we first review the use cases expecting plain HTTP traffic and discuss the extent to which TLS hinders these operations. We retain 19 scenarios where access to unencrypted traffic is still relevant and evaluate the incentives of the stakeholders involved. Second, we survey techniques and proposals by which TLS no longer delivers end-to-end security, and by which the notion of an "end" changes. We therefore include endpoint-side middleboxes and mid-path caching middleboxes such as Content Delivery Networks (CDNs), alike. Finally, we compare each scheme based on deployability and security characteristics, and evaluate their compatibility with the stakeholders' incentives. Our analysis leads to a number of findings and observations that we believe will be of interest to practitioners, policy makers and researchers.Comment: 34 page